Frankly this PR is too big to give a meaningful review across the entire thing without having some hands on experience. I roughly "get it", but I'll likely have a better handle on things once we go through trying to deploy this.

One overall thing that isn't quite clear to me is how I would extend/consume the underlying framework you have to start replacing the emmet-api. What would I need to do to replace the summary endpoint for example?

Is there some "core abstraction" running through this that I/we could build from to replace emmet-api's internals?

Yeah, it's quite large...

For merging, it would be primarily the server architecture. We would make a "shared kernel" package of the "base" files (app, authz, dependencies, etc.) and make them more general (ie. parameterize the app factory). Then include the Resource.routers into the new app framework, use improved error handling, and switch our logging. We would also consolidate our data access logic with repositories (one class for MPContribs, one Read-Only class for emmet), pagination, and use fastapi-filter.

Sharing the domain logic (our ODM, repos, services, models) is more difficult by nature. emmet is many read-only collections, so it makes sense to have factories/registries to handle efficient creation, while MPContribs collections have different behaviors.

The core abstraction is Router -> Filter -> (service) -> Repository(scope, pagination) -> SparseFieldsModel (projects/ is a good example). We'd shift emmet like: QueryOperators -> Filter, SparseFieldsQuery -> SparseFieldsModel, GlobalHeaderProcessor -> scope, PaginationQuery -> Page+CursorParams. This isn't directly possible today - we need to define a ReadOnlyRepository that doesn't use Beanie and to create the "shared kernel".

Addressing the Summary endpoint: most of the declaration would live in SummaryFilter (we'd include all fields, and most likely have to generate the __gte, __lte, etc. fields), and header_processor and query_to_configure_on_request would be removed in favor of scope. I'd also most likely want to move towards a simpler registry pattern - ideally just define a Filter and add a line to the registry.

For merging, it would be primarily the server architecture. We would make a "shared kernel" package of the "base" files (app, authz, dependencies, etc.) and make them more general (ie. parameterize the app factory). Then include the Resource.routers into the new app framework, use improved error handling, and switch our logging. We would also consolidate our data access logic with repositories (one class for MPContribs, one Read-Only class for emmet), pagination, and use fastapi-filter.

yep this would be great to work towards

Sharing the domain logic (our ODM, repos, services, models) is more difficult by nature. emmet is many read-only collections, so it makes sense to have factories/registries to handle efficient creation, while MPContribs collections have different behaviors.

Intuition says that at least the bones of the api logic should/will be sharable, and then yes the individual 'front ends' (emmet/contribs) would have to handle defining their respective models, etc.

ReadOnlyRepository that doesn't use Beanie

any particular reason we can't use Beanie for everything that touches mongo?

Sharing the domain logic (our ODM, repos, services, models) is more difficult by nature. emmet is many read-only collections, so it makes sense to have factories/registries to handle efficient creation, while MPContribs collections have different behaviors.

Intuition says that at least the bones of the api logic should/will be sharable, and then yes the individual 'front ends' (emmet/contribs) would have to handle defining their respective models, etc.

Definitely can be, but it depends how much boilerplate we want to manage. Ie. Adding a folder that contains a router.py, repo.py, and models.py for a few GET routes (no POST/PUT/DELETE/PATCH) that utilize a single model - not complex, but we could *probably* get the same done with fewer LOC by generating in a similar way to how we do it now.

ReadOnlyRepository that doesn't use Beanie

any particular reason we can't use Beanie for everything that touches mongo?

100% can. It would unify how we interact with models, just again turns into a tradeoff of the extra boilerplate being worth it. It might end up reducing code elsewhere, so could be a win regardless.